x/crosschain/client/cli/cli_whitelist_erc20.go (1)

18-18: Enhance command description with parameter format details.

Add details about the expected format and constraints of the liquidityCap parameter in the command description.

-		Use:   "whitelist-erc20 [erc20Address] [chainID] [name] [symbol] [decimals] [gasLimit] [liquidityCap]",
+		Use:   "whitelist-erc20 [erc20Address] [chainID] [name] [symbol] [decimals] [gasLimit] [liquidityCap (uint)]",
+		Long:  "Add a new erc20 token to whitelist. The liquidityCap parameter specifies the maximum allowed liquidity in base units.",

x/fungible/client/cli/tx_deploy_fungible_coin_zrc_4.go (1)

18-18: Enhance command description with parameter format details.

Add details about the expected format and constraints of the liquidityCap parameter in the command description.

-		Use:   "deploy-fungible-coin-zrc-4 [erc-20] [foreign-chain] [decimals] [name] [symbol] [coin-type] [gas-limit] [liquidity-cap]",
+		Use:   "deploy-fungible-coin-zrc-4 [erc-20] [foreign-chain] [decimals] [name] [symbol] [coin-type] [gas-limit] [liquidity-cap (uint)]",
+		Long:  "Deploy a fungible coin ZRC4 contract. The liquidity-cap parameter specifies the maximum allowed liquidity in base units.",

e2e/e2etests/test_solana_whitelist_spl.go (2)

44-44: Improve readability of the liquidity cap value.

The hardcoded value would be more maintainable and readable if defined as a constant with a descriptive name.

+const (
+	// TestLiquidityCap represents 100M tokens with 18 decimals
+	TestLiquidityCap = "100000000000000000000000000"
+)

-		sdkmath.NewUintFromString("100000000000000000000000000"),
+		sdkmath.NewUintFromString(TestLiquidityCap),

---

42-45: Consider adding test cases with different liquidity cap values.

The test would be more comprehensive with additional test cases that verify the behavior with different liquidity cap values, including edge cases.

Consider adding test cases for:

• Minimum acceptable value
• Maximum value that can be handled
• Zero value (should fail)

x/fungible/types/message_deploy_fungible_coin_zrc20_test.go (1)

68-81: Enhance test coverage for liquidity cap validation.

While the nil check test case is good, consider adding test cases for:

• Zero liquidity cap
• Maximum allowed liquidity cap
• Negative values (if applicable to the type)

{
    name: "zero liquidity cap",
    msg: types.NewMsgDeployFungibleCoinZRC20(
        sample.AccAddress(),
        "test erc20",
        1,
        6,
        "test",
        "test",
        coin.CoinType_ERC20,
        10,
        sdkmath.ZeroUint(),
    ),
    err: sdkerrors.ErrInvalidRequest,
},
{
    name: "excessive liquidity cap",
    msg: types.NewMsgDeployFungibleCoinZRC20(
        sample.AccAddress(),
        "test erc20",
        1,
        6,
        "test",
        "test",
        coin.CoinType_ERC20,
        10,
        sdkmath.NewUintFromString("115792089237316195423570985008687907853269984665640564039457584007913129639935"),
    ),
    err: sdkerrors.ErrInvalidRequest,
},

e2e/e2etests/test_whitelist_erc20.go (1)

44-44: Consider documenting the liquidity cap value.

The large value (100000000000000000000000000) would benefit from:

1. A named constant with documentation explaining the choice
2. Verification that the cap was correctly set after whitelisting

+// DefaultTestLiquidityCap represents 100M tokens with 18 decimals
+const DefaultTestLiquidityCap = "100000000000000000000000000"

-sdkmath.NewUintFromString("100000000000000000000000000"),
+sdkmath.NewUintFromString(DefaultTestLiquidityCap),

Additionally, consider adding verification:

// Verify liquidity cap was set correctly
cap, err := erc20ZRC20.LiquidityCap(&bind.CallOpts{})
require.NoError(r, err)
require.Equal(r, DefaultTestLiquidityCap, cap.String())

x/crosschain/keeper/utils_test.go (1)

171-172: Consider parameterizing the liquidity cap in test helpers.

Both setupGasCoin and deployZRC20 use a hardcoded value of 1000 for the liquidity cap. Consider making this a parameter to enable testing different scenarios and edge cases.

 func setupGasCoin(
 	t *testing.T,
 	ctx sdk.Context,
 	k *fungiblekeeper.Keeper,
 	evmk *evmkeeper.Keeper,
 	chainID int64,
 	assetName string,
 	symbol string,
+	liquidityCap sdkmath.Uint,
 ) (zrc20 common.Address) {

Also applies to: 198-199

e2e/e2etests/test_migrate_chain_support.go (2)

83-83: Consider using a more realistic test value for liquidity cap.

The current value of "100000000000000000000000000" (1e26) might be unnecessarily large for testing purposes. Consider using a smaller, more realistic value that still validates the functionality.

-			sdkmath.NewUintFromString("100000000000000000000000000"),
+			sdkmath.NewUintFromString("1000000000000000000"), // 1e18

---

170-170: Avoid duplicating magic numbers.

The liquidity cap value is duplicated. Consider extracting it to a constant for better maintainability.

+const testLiquidityCap = "1000000000000000000" // 1e18
+
 // ... later in the code ...
-			sdkmath.NewUintFromString("100000000000000000000000000"),
+			sdkmath.NewUintFromString(testLiquidityCap),

x/crosschain/keeper/msg_server_whitelist_erc20_test.go (1)

84-84: Extract test value to a constant.

The liquidity cap value of 1000 is used repeatedly throughout the test file. Consider extracting it to a constant for better maintainability and clarity.

+const testLiquidityCap = uint64(1000)
+
 // ... in the test ...
-				LiquidityCap: sdkmath.NewUint(1000),
+				LiquidityCap: sdkmath.NewUint(testLiquidityCap),

 // ... in assertions ...
-				uint64(1000),
+				testLiquidityCap,

Also applies to: 99-104

docs/spec/fungible/messages.md (1)

46-46: Fix formatting: Replace hard tab with spaces.

Replace the hard tab with spaces to maintain consistent formatting throughout the documentation.

🧰 Tools

🪛 Markdownlint (0.37.0)

46-46: Column: 1
Hard tabs

(MD010, no-hard-tabs)

docs/spec/crosschain/messages.md (1)

214-214: Replace hard tab with spaces.

For consistency with Markdown formatting standards, replace the hard tab with spaces.

🧰 Tools

🪛 Markdownlint (0.37.0)

214-214: Column: 1
Hard tabs

(MD010, no-hard-tabs)

e2e/txserver/zeta_tx_server.go (2)

436-437: Consider extracting the liquidity cap constant.

The magic number 100000000000000000000000000 (100M * 10^18) should be extracted as a named constant at the package level for better maintainability and reusability.

 const (
+    // DefaultLiquidityCap represents the default liquidity cap of 100M tokens with 18 decimal places
+    DefaultLiquidityCap = "100000000000000000000000000"
 )

 // ZetaTxServer implementation...
 
 func (zts ZetaTxServer) DeployZRC20s(...) (*ZRC20Addresses, error) {
-    liquidityCap := sdkmath.NewUintFromString("100000000000000000000000000")
+    liquidityCap := sdkmath.NewUintFromString(DefaultLiquidityCap)

---

Line range hint 438-493: Consider parameterizing the liquidity cap.

The same liquidity cap is applied to all tokens regardless of their characteristics (gas tokens vs. ERC20). Consider making it configurable per token type or accepting it as a parameter in the DeployZRC20s function.

Example refactor:

 type ZRC20Deployment struct {
     ERC20Addr common.Address
     SPLAddr   *solana.PublicKey
+    LiquidityCap sdkmath.Uint // Add liquidity cap parameter
 }

 func (zts ZetaTxServer) DeployZRC20s(
     zrc20Deployment ZRC20Deployment,
     skipChain func(chainID int64) bool,
+    defaultLiquidityCap sdkmath.Uint,
 ) (*ZRC20Addresses, error) {

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro